Content providers

Table of contents

• Introduction
• Custom Content Providers and the ContentProvider class
• Custom Page Providers and the PageProviderBase class
• Integrating the XMLPageProvider
• See Also

Introduction

The content provider technology is one way of integrating information into an EPiServer CMS website. You can use EPiServer Custom Content Providers for the management of information from a site. This is a way of getting access to data in the Web solution without moving the data into EPiServer CMS. By building one or more Custom Content Providers, you can consolidate all data in one CMS. Users will have an integrated user experience and all the "normal" EPiServer CMS functions will work both for editors and developers.

The content provider acts as an intermediary connecting an EPiServer CMS site to an external data source. All the data appears as part of the EPiServer CMS website, though in fact the data resides at the data source. The data handled by the content provider can be displayed as EPiServer CMS EPiServer.Core.IContent instances only.

A PageProvider (a class that inherits EPiServer.Core.PageProviderBase) is a specific type of ContentProvider that handles pages only. At runtime a page provider is wrapped in a EPiServer.Core.PageProviderWrapper instance that is a ContentProvider.

A sample page provider XMLPageProvider is shipped with EPiServer CMS, to be used as inspiration to developers when creating custom page providers.

Content providers are registered/configured in web.config or through EPiServer.Core.IContentProviderManager. Since there is no default content provider information in the web.config, you need to add this information manually. Concerning the capabilities a content provider instance can support, see Configuring Content Providers.

• Data resides in original store. The data is not stored in the local EPiServer CMS website database, the data source is integrated with EPiServer CMS.
• Requires coding and configuration. Registered content providers need to inherit from ContentProvider (or PageProviderBase) class. Configuration/registration of a content provider shall be added to the web.config or registered through IContentProviderManager.
• Sample page provider available. The XMLPageProvider sample page provider is shipped with EPiServer CMS, available for download on EPiServer World.
• IContent only. The information/data from a content provider appears as EPiServer CMS content only.
• DefaultContentProvider technology. EPiServer CMS uses the content provider concept internally as well, that is the local pages/content served by the EPiServer CMS database is also delivered through a content provider: DefaultContentProvider. The sample XMLPageProvider is a custom page provider.
• RemotePageProvider technology. A RemotePageProvider integrates one EPiServer CMS web solution with another. An EPiServer CMS site can have several different Remote Page provider instances registered with each of them having their own set of configuration data such as binding and capabilities settings etc. The Remote Page Provider is based on WCF framework.
• Enable/Disable Content Provider Functionality. In order to be able to move content between content providers special permissions must be switched on in Admin mode: Permissions for functions: "Move between page providers". A warning dialog is displayed as an extra precaution when attempting to move pages between providers.

Custom content providers and the ContentProvider class

Each content provider that is registered with EPiServer CMS must inherit from the ContentProvider class that resides in the EPiServer.dll assembly. When creating custom content providers there is only one abstract method that is required to be implemented:

• LoadContent. What is used to pull out one specific content instance from the data store and return it – an instance of an object that is implementing the IContent interface (for example PageData).

There are alot of additional methods in ContentProvider class that can be overridden and implemented to offer more functionality to the content provider. Below are some example on methods:

• LoadChildrenReferences. Only passing back the content references for all the children to one specific node. This should be implemented if provider is registered with an entry point and thereby displayed in page tree.
• ContentResolveResult ResolveContent(ContentReference). Needs to be implemented to support permanent links. From a ContentReference to a GUID and a Uri. If the passed in identifier corresponds with an identifier for a content served by the content provider instance then this method should return the internal ("classic" link to the content and the Guid based identifier for the content. The URI can be constructed by helper method ConstructContentUri(contentTypeId, contentLink, contentGuid). This maps to PageLink, PageGUID and LinkUrl properties for a PageData instance.
• ContentResolveResult ResolveContent(Guid). Needs to be implemented to support permanent links. From a GUID to a ContentReference/Uri. If the passed in identifier corresponds with an identifier for a content served by the content provider then the implementation should return the internal ("classic") link to the content and set ContentReference identifier. The URI can be constructed by helper method ConstructContentUri(contentTypeId, contentLink, contentGuid). This typically maps to PageLink, PageGuid and LinkUrl properties for a PageData instance.

Custom page providers and the PageProviderBase class

Each page provider that is registered with EPiServer CMS must inherit from the PageProviderBase class that resides in the EPiServer.dll assembly. When creating custom page providers there are four abstract methods that are required to be implemented:

• GetLocalPage. What is used to pull out one specific page from the data store and return it – a PageData object or an instance of an object that is derived from the PageData class. There are some helper methods in PageProviderBase to initialize and populate PageData objects.
• GetChildrenReferences. Only passing back the page references for all the children to one specific node (the rest EPiServer CMS takes care of, caching, sorting etc).
• Uri ResolveLocalPage(PageReference, out Guid). From a pageReference to a GUID. If the passed in identifier corresponds with an identifier for a page served by the page provider instance then this method should return the internal ("classic" link to the page and the Guid based identifier for the page. This maps to PageLink, PageGUID and LinkUrl properties for a PageData instance.
• Uri ResolveLocalPage(Guid, out PageReference). From a GUID to a pageReference. If the passed in identifier corresponds with an identifier for a page served by the page provider then the implementation should return the internal ("classic") link to the page and set PageReference identifier. The URI can be constructed by helper method ConstructPageUri(Int32, PageReference). This typically maps to PageLink, PageGuid and LinkUrl properties for a PageData instance.

Integrating the XMLPageProvider

This section describes how you can add the XMLPageProvider to an EPiServer CMS website, you only need to perform a few simple steps in order get the page provider working in the solution. Here with have used the XMLPageProvider as an example:

Step 1: Create a page provider entry point. Insert a page provider node in the site's page tree (an empty page), an entry point for the page provider. Note the Page ID which shall be the entry point value in the page provider configuration.

Step 2: Add the XmlPageProvider Assembly to the solution. Add the assembly XmlPageProvider.dll to the projects references.

Step 3: Add the data source. The file externalpages.xml is available for download on EPiServerWorld, prepared as the data storage for this demonstration. The path and file name for the data file is stored in the attribute filePath in the path provider configuration in the web config file.

Step 4: Add the configuration to web.config. See Configuring Content Providers.

Using the page provider

Now you can access and manipulate the information in the page provider node in EPiServer CMS. Which actions can be carried out on the page provider node is defined by the capabilities attribute in the configuration. Be careful when moving pages between one page provider to another - when the information is moved into another page provider it is deleted from the old page provider permanently.

See also

For further information see the SDK framework reference PageProviderBase class methods for some detailed information regarding the XMLPageProvider implementation.